Skip to content

fix(backpack-api): reject with response.statusCode instead of response.status#10072

Open
Chessing234 wants to merge 1 commit into
scratchfoundation:developfrom
Chessing234:fix-backpack-api-error-uses-undefined-status-property
Open

fix(backpack-api): reject with response.statusCode instead of response.status#10072
Chessing234 wants to merge 1 commit into
scratchfoundation:developfrom
Chessing234:fix-backpack-api-error-uses-undefined-status-property

Conversation

@Chessing234
Copy link
Copy Markdown

Bug

Every backpack xhr callback rejects with `new Error(response.status)`, but the surrounding check is `response.statusCode !== 200`. As a result, every non-2xx response (and every error path) bubbles up as `Error: undefined` to callers, hiding the real HTTP code from logs and UI.

```js
if (error || response.statusCode !== 200) {
return reject(new Error(response.status)); // response.status === undefined
}
```

Root cause

This file uses the `xhr` npm package, whose response object exposes the HTTP code as `statusCode`, not `status`. The status check on the same line uses the correct name; only the error-construction half of each pair was wrong. Same copy-paste typo across all four functions (`getBackpackContents`, `saveBackpackObject`, `deleteBackpackObject`, `fetchAs`).

Fix

Pass `response.statusCode` into the `Error` so the rejection actually carries the HTTP code. Mechanical 4-line change matching the check immediately above each line.

…s undefined)

All four backpack xhr callbacks branch on 'response.statusCode !== 200'
but then call 'reject(new Error(response.status))'. The xhr npm package
exposes the HTTP code as 'statusCode', not 'status', so every rejection
surfaced an Error whose message was the literal string 'undefined',
hiding the actual failure code from callers/logging. Switch the error
constructor to use 'response.statusCode' to match the check on the
same line.
@github-actions
Copy link
Copy Markdown


Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.


I have read the CLA Document and I hereby sign the CLA


You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant